BBS Toolkit/BBS Toolkit.iso/rbbs_pc/rbbsdocs.zip/RBBSDOCS.17

Text File | 1990-11-05 | 19KB | 335 lines

    MESSAGE AREAS WITHIN RBBS-PC                                           17-1


    17. MESSAGE AREAS WITHIN RBBS-PC
    --------------------------------
    RBBS-PC is intended to be an open system.  As such it can have an unlimited
    number of message areas  and messages.  At the very minimum,  RBBS-PC has a
    single

      1) message area, a file named MESSAGES,
      2) user file, a file named USERS, and
      3) definition file, a file named RBBS-PC.DEF

    In addition to  this, additional messages  areas can  be created as  either
    "conferences" (i.e.  areas that use  the same RBBS-PC.DEF file  as the main
    RBBS-PC message area) or "sub-boards" (i.e. areas that have their own  .DEF
    file).

    17.1 "Conferences" and "Sub-boards" -- the Differences
    ------------------------------------------------------
    A "conference" or "sub-board" can be:

      1) "public" -- any caller can join.
      2) "public with a separate user file"  -- any caller can join and RBBS-PC
         remembers  the  last message  read by  each caller  and will  notify a
         caller on logon that new mail is waiting.
      3) "semi-public" -- only callers with security levels equal to or greater
         than that specified for the conference can join.
      4) "semi-public  with a separate user file" -- only callers with security
         levels equal to or greater than  that specified for the conference can
         join  and RBBS-PC remembers  the last message read  by each caller and
         mail waiting.
      5) "private  with a  separate user  file" -- only  callers who  have been
         pre-registered in the separate  user file for the conference  can join
         and RBBS-PC remembers the last message read and mail waiting.

    A "sub-board" is just a conference that also has a configuration definition
    file (.DEF).   Sub-boards can be public, private, or  semi-private.  Access
    to a  sub-board is controlled by the configuration parameter 123 which sets
    the   minimum  security  level  required  to  enter  the  "sub-board."    A
    "sub-board"  configuration file  has the  same format  as the  RBBS-PC main
    configuration  file,  and is  created and  edited  using CONFIG.EXE.   This
    allows  a  "sub-board"  to have  its  own  unique  welcome file,  commands,
    security levels, menus, help,  bulletins, directories, and up  and download
    areas.  "Sub-boards" can share as  much or as little as desired  with other
    conferences or other "sub-boards" within the same RBBS-PC system.  The only
    things a "sub-board"  cannot change are the  primary MESSAGES file and  the
    communications parameters used by the RBBS-PC it is running under.

    To  the caller,  a "sub-board"  appears just  like another  bulletin board,
    accessed from a bulletin board rather than through a telephone number.

    Public  sub-boards,  just  like  public  boards, are  those  whose  minimum
    security to  join is not  higher than the  default security for  new users.
    "Sub-boards"  basically  allow a  single  telephone  number  to offer  very
    different types and levels of services.  Independent "sub-boards" run under
    the  same  RBBS-PC service  radically  different  types of  terminals/PC's.
    Within the same RBBS-PC, one  "sub-board" may have 80 column menus  for IBM
    and  compatible PC callers, another may have  40 column menus for Atari and
    Commodore PC  users, and still another  may have 20 column  menus for those
    using  telecommunications devices  for the deaf  (TDD's).  No  longer is it
    necessary to provide  three independent  telephone numbers  for three  such



    RBBS-PC 17.3A            TECHNICAL REFERENCE MANUAL                    17-2


    different services.  All callers can dial the same number and simply switch
    over to the appropriate board.  Extra lines can be added to a roll-over and
    service all the boards.  "Sub-boards"  make it much easier and feasible for
    a SysOp to market bulletin board services by allowing hardware to resources
    to be pooled under one software "umbrella" such as RBBS-PC  and yet service
    a very  diverse set of  requirements -- much  the same way  that Compuserve
    does.  One  of the best  hardware configurations for running  a multi-board
    service like  this  is  PC-Slaves, because  adding  additional  boards  are
    extremely easy, with virtually no system degradation.

    "Sub-boards"  greatly benefit  "umbrella"  organizations.   For example,  a
    computer  club that covers IBM computers,  Apple, Atari, and Commodore.  No
    longer does software intended for one type of computer have to get mixed in
    with listings  for another  computer.   Each  computer  can have  not  only
    separate messages, but bulletins and directories as well.

    "Sub-boards"  make it easy  to have different "levels"  of service based on
    security level.  Many SysOps run  both a "free" and a "subscription" board.
    The  most typical arrangement for this is to  have the free board be on the
    bottom  of a telephone roll-over and  the pay board be on  the top, and for
    the top board to require a higher security level.  Non-subscribers who call
    the pay board number get "kicked" off the board.  "Sub-boards" on the  same
    telephone  line would give both paying and non-paying callers equal access,
    if  desired.  Another  example is that  callers with enhanced  security can
    join  a sub-board  to get  access to  even more  downloads.   Or, executive
    officers for an organization can have access to a "sub-board"  that has not
    only special messages but special bulletins and files.

    The naming conventions of the files associated with a "conference" or "sub-
    board", for example called CLONES, would be:

    CLONESM.DEF    --- the message file
    CLONESU.DEF    --- the user file
    CLONESW.DEF    --- the "welcome" file (for conferences only)
    CLONESC.DEF    --- the configuration file (for "sub-boards" only)

    Using the configuration .DEF file associated with a "sub-board" allows each
    SysOp to  make the  "sub-boards"  as unique  or similar  as  desired.   Two
    security levels are very important.  The  minimum security to log on to the
    board determines who  can join the  "sub-board".  And the  default security
    level is what newly added callers are assigned.

    A  "sub-board", like any  conference (public, semi-private,  or private) is
    closed  to  all who  have  insufficient security.   To  make  a "sub-board"
    completely  private,  simply set  the  minimum  CONFIG parameter  123  (the
    minimum  security level a new  user needs to  logon) to be  higher than any
    normal caller would have.   The only way for  callers to be able to  join a
    completely  private "sub-board", like a private conference is for the SysOp
    to have  added them previously to the users file associated with that "sub-
    board".

    The  security level a caller  gets when auto-added  is the default security
    level for the "sub-board" and not the current security level of the caller.
    This is to prevent special privileges  that a caller has in one "sub-board"
    from  automatically propagating into  other "sub-boards".   For  example, a
    caller with SysOp privileges in one "sub-board" who joins  another does not
    become receive SysOp privileges in the other.



    MESSAGE AREAS WITHIN RBBS-PC                                           17-3


    The security level used to determine what "sub-boards" a caller can join is
    not the current  security level but the original  security level the caller
    had on the main board.

    RBBS-PC detects if the bulletins in the "sub-board" are the same  as in the
    main  RBBS-PC system and  does not  re-display them  when a  "sub-board" is
    joined.

    "Sub-boards",  public conferences,  semi-private  conferences, and  private
    conferences can all co-exist within the same RBBS-PC system.  Sub-boards in
    turn can have  sub-boards in  them, as  well as  public, semi-private,  and
    private conferences.

    The  primary  disadvantage  of  "conferences"  or  "sub-boards"  that  have
    separate user files associated  with them is the additional disk space that
    is required  for the users file.  RBBS-PC's CONFIG parameter 290 allows the
    SysOp to let a  user on as a "guest" if  there is no more room left  in the
    users  file  for  the  "sub-board",  semi-private  conference,  or  private
    conference.   Not having a user  record defeats one of  the main mechanisms
    for remembering a  user's preferences, of course,  but the SysOp  can start
    with a  smaller users  file and  expand later without  the risk  of denying
    callers access.

    Obviously, "sub-boards" take more time to set up and maintain.  While it is
    nice to be able to  have parts of RBBS-PC vary radically from  one another,
    every one  that does vary  is another item to  create and maintain.   "Sub-
    boards"  can  multiply  the  work   necessary,  for  example,  to  maintain
    bulletins.   There are more users  and message files to  oversee.  However,
    Kim Wells  MU-EDIT is an invaluable tool  for managing multiple message and
    user  files.  Give Kim's RBBS-PC call at [phone]/7652 and get a copy
    of MU-EDIT.

    17.2 Making a "Conference" or "Sub-board" Successful
    ----------------------------------------------------
    To make a "conference" or "sub-board" successful several guidelines should
    be followed rather rigorously:

      1) Establish  a "conference"  or "sub-board" chairman  (i.e. a  SysOp) to
         manage the conference. The SysOp's job is to add new users, delete old
         ones, make  sure that the subject and/or  the agenda of the conference
         is adhered  to by killing  messages that are  inappropriate.  This  is
         best accomplished by having a separate user file for each "conference"
         or "sub-board" in  which the caller only has SysOp  privileges when in
         the specific "conference" or "sub-board."

      2) Establish an "agenda" or list of subject areas for the "conference" or
         "sub-board."   One of these should be  about new subject areas.  These
         areas  should be  VERY  narrow in  scope.   The  essence  of any  good
         conference is keeping it focused.   Everyone has been in at  least one
         meeting/conference  that  was  a waste  of  time  because whoever  was
         running  the meeting/conference did not keep  the dialogue centered on
         the subject or agenda.

      3) If a continuity of dialogue is to be achieved, it is advisable to keep
         the conference "focused" -- either by keeping the number of conference
         members  limited,  or  by  keeping  the  subject  matter  very narrow.
         Another  interesting thing about  "private" conferences and sub-boards
         as  implemented  within RBBS-PC  is that  they  are not  "public" and,



    RBBS-PC 17.3A            TECHNICAL REFERENCE MANUAL                    17-4


         therefore, are even  more protected  by the first,  fourth, and  fifth
         amendments.

    17.3 Setting Up a "Conference" or "Sub-board"
    ---------------------------------------------
    The SysOp sets up a "conference"  using the CONFIG utility parameter 167 to
    pre-format up to  two files -- one  for the messages to be  associated with
    the conference  and one for the  users to be associated  with a conference.
    The name  of a "conference"  can be from  one to seven  characters that are
    valid  for a  file  name.   RBBS-PC  will add  "M" (for  the  messages file
    associated the conference) or a "U" (for the users file associated with the
    conference)  to the  filename.   The  SysOp can  then enter  the conference
    member's names  in the conference USERS file by using the SysOp function 5.
    The  SysOp can  "join" any  conference and  need not  be in  any particular
    conference's USERS file.

    Like "conferences", RBBS-PC  supports an unlimited number of  "sub-boards".
    "Sub-boards" are  equally easy  to create.   If CLONES were  the name  of a
    public  conference (the CLONES  message file CLONESM.DEF  exists), all that
    would  have to be done to make CLONES  a "sub-board" would be to run CONFIG
    to
      1) create a separate  user's file, CLONESU.DEF, for  this formerly public
         conference (if didn't already have a users file),
      2) create a  "sub-board"   configuration file for the  CLONES "sub-board"
         (a file whose name would be ATARIC.DEF).

    The easiest way to make a "sub-board" configuration file is to use  the DOS
    copy command, starting with another configuration file as a model (e.g. the
    one  for the main  board).  To  continue with the CLONES  example you would
    issue the DOS command:

         COPY RBBS-PC.DEF  CLONESC.DEF

    Then invoke CONFIG.EXE to edit that file, using the form

         CONFIG CLONESC.DEF

    WARNING!!   When you create a .DEF file  by copying another one as a model,
    be sure to run CONFIG against this new file and change the message and user
    file names!  Otherwise your sub-board will share the user file with another
    message base.   Here change the  message file name  to CLONESM.DEF and  the
    user file  name to CLONESU.DEF.  The users file  name can be anything for a
    "sub-board"  but  the  extension .DEF  is  a  good  idea because  RBBS-PC's
    security system will  not let any file  with that extension be  downloaded.
    Remember, you do not want to allow callers to download any users file!  You
    get  an  extra layer  of  protection  if you  put  the  message, user,  and
    configuration files in an area not available for downloading.

    17.4 Conference File Locations
    ------------------------------
    The files that make up a conference or a sub-board can be placed in several
    locations.  Especially on multi-node BBSs, care must be taken when locating
    conference files.

    If  a  sub-board CONFIG  files exists,  it must  either  be in  the RBBS-PC
    default  directory, or  in  the directory  where the  MAIN message  file is
    located.   NOTE: If  a caller  joins a sub-board  from within  another sub-
    board, the  MAIN message file location  would be the location  of the first



    MESSAGE AREAS WITHIN RBBS-PC                                           17-5


    sub-board.  Once a sub-board CONFIG file is found, all other file locations
    will be set by the CONFIG file parameters.

    If  there is no  CONFIG file,  RBBS-PC will next  look for  a MESSAGE file.
    First, the subdirectory where the current MAIN message file is located will
    be searched, and then  the directory where the conference  description file
    is located (see CONFIG parameter 74) will be searched.

    To find the USER file, RBBS-PC first looks where the current MAIN user file
    is located, and then in the RBBS-PC default directory.

    This may seem complex, and for most SysOps, placing all CONFIG, MESSAGE and
    USER files in the  default subdirectory is  adequate.  CONFIG will  create,
    and  locate conference and sub-board  files properly when  parameter 167 is
    slected.

    17.5 Establishing a "Conference" or "Sub-board" SysOp
    -----------------------------------------------------
    RBBS-PC  has one of the  more flexible and  powerful systems for supporting
    "assistant SysOps" or  "conference moderators".   A moderator  need not  be
    made a full SysOp, and whatever security a moderator has, does not transfer
    to the rest of the board.   Moderators need the following basic functions:

      1) read and kill all messages,
      2) add and modify users, and
      3) forward mail to a better person to answer it.

    The  ability to do  user edits is  controlled by the  security specified by
    SysOp function 5.   Incidentally, moderators cannot edit user  records with
    security  higher than theirs.  The ability to read and kill all messages is
    controlled  by  a security  level specified  in  CONFIG.   RBBS-PC supports
    having  separate user  files  for every  message  area, so  that  moderator
    privileges in one area do not necessarily transfer to others.

    To set up a conference or sub-board moderator,  the SysOp need only

      1) "Join" the conference or sub-board.
      2) Use SysOp function 5  to enter the name of the user who  is to  be the
         conference chairperson into the conference's USERS file.
      3) Set  that users security  level in the  conference's USERS file   to a
         security  level that can issue the SysOp  function 5.  This will allow
         the conference chairman to add users.
      4) Set the minimum security to read and kill all messages to the level of
         the moderator.
      5) Set the  minimum security to  change the  minimum security  to read  a
         message to the  security level of the moderator.   This will allow the
         moderator to forward everyone's mail.

    Any registered  user can  join a  "public" conference  or sub-board.   When
    someone issues the J)oin command  to join a conference or sub-board,  their
    standard security  level is temporarily  superseded by  the security  level
    associated with  their user  name within that  conference's or  sub-board's
    USERS file if it is a "private" conference.

    For example,  a normal user  might be  given the security  required to  add
    users to a particular conference or sub-board USERS file since they are the
    SysOp of that message area.  When  a user joins the conference or sub-board
    of which they are chairman, their normal security is bumped up so that they
    can add users  to the USERS file of that particular message area.  When the



    RBBS-PC 17.3A            TECHNICAL REFERENCE MANUAL                    17-6


    same user  exits that message  area, their  security level  is returned  to
    normal.  If  they should subsequently join another  message area where they
    are not chairman, they would be unable to add  users to that message area's
    USERS  file.  Other than  a message area's SysOp, none  of the message area
    members should be given any higher security than they otherwise  enjoy as a
    regular RBBS-PC user.